Давно мы не публиковали таблицу сравнения изданий VMware vSphere, а ведь в версии vSphere 6.0 много что изменилось, поэтому иногда полезно взглянуть на таблицу ниже. Кроме того, помните, что с 30 июня колонок в таблице станет на одну меньше - издание vSphere Enterprise снимается с продаж.
Возможность / Издание VMware vSphere
Hypervisor 6 (бесплатный ESXi)
vSphere Essentials 6
vSphere Essentials Plus 6
vSphere Standard 6
vSphere Enterprise 6.0 - (снимается с продаж 30 июня 2016 года
В этом посте мы расскажем об основных изменениях и нововведениях, которые произойдут в составе пакетов решений VMware vCloud Suite 7 и VMware vRealize Suite 7, и о которых VMware рассказала на прошлой неделе. Напомним, что о прошлой версии vCloud Suite 6 мы писали вот тут, а о vRealize Suite немного писали здесь.
Продукты семейства vRealize преподносятся как средства трансформации ИТ:
Начнем с изменения цен, комплектации и лицензирования.
1. Изменения в изданиях vRealize Suite 7.
Теперь vRealize Suite 7 поставляется в трех изданиях:
Новое издание Standard Edition, добавленное в линейку vRealize Suite, предназначенное для реализации базовых операций по автоматизации датацентра.
Advanced Edition - это более серьезное издание для ИТ-организаций, строящих IaaS-инфраструктуру. Здесь уже используются средства облачной инфраструктуры для доставки сервисов пользователям, а также предоставляются средства самообслуживания при запросе ресурсов.
Enterprise Edition - здесь уже полный набор облачных инструментов для автоматизации и управления инфраструктурой на всех уровнях от аппаратного до уровня облачных приложений.
Вот какие продукты будут присутствовать в каждом из изданий:
2. Изменения в изданиях vCloud Suite 7.
Теперь vCloud Suite выровнен по изданиям с vRealize Suite, поэтому клиентам VMware будет понятно, какое издание vCloud Suite нужно, если подобрано издание vRealize Suite, и наоборот.
Обратите внимание, что в данном случае платформа виртуализации доступна только в одном издании - vSphere Enterprise Plus.
3. Новая модель лицензирования на базе Portable Licensing Unit (PLU).
Теперь вводится такая единица лицензирования PLU, которая предназначена для унификации лицензирования в разнородных инфраструктурах, которые могут быть построены онпремизно или в публичном облаке на базе решений различных вендоров. Одна лицензия PLU позволяет использовать неограниченное число Operating System Instances (OSIs) / Virtual Machines (VMs) на одном процессоре (CPU) под управлением гипервизора vSphere, либо 15 экземпляров OSI/VM в других инфраструктурах (к примеру, в публичном облаке другого вендора, например, Amazon или на базе другого гипервизора). При этом использование одной лицензии PLU допускается только в рамках одного типа лицензирования (vSphere или 15 экземпляров).
Более подробно о комплектации и лицензировании vRealize Suite можно прочитать вот в этом документе.
Текущие пользователи при обновлении на седьмые версии пакетов продуктов получат сразу и обновление лицензирования. А вот для пользователей отдельных продуктов, купленных независимо от сьютов (VMware vRealize Operations, vRealize Automation, vRealize Business for Cloud, vRealize Log Insight, vRealize Code Stream) - ничего не поменяется, их лицензии нельзя будет сконвертировать в PLU.
4. Новые возможности продуктов в составе VMware vCloud Suite 7 и VMware vRealize Suite 7.
Конечно же, как и всегда, в составе отдельных продуктов пакетов появятся новые возможности и улучшения существующих функций.
VMware vRealize Automation 7.0
Тут добавилось много нового:
Упрощение конфигурации - теперь с дефолтными настройками можно развернуть решение в 6 раз быстрее предыдущей версии. Все остальное стало более упорядоченным и логичным:
Новые шаблоны для быстрого составления архитектурного плана - теперь такие компоненты, как compute infrastructure, networks, security и software легко связывать между собой в переработанном интерфейсе.
Работа с решением VMware NSX прямо из консоли vRealize Automation 7.0 - теперь работать с логическими сервисами NSX можно средствами интерфейса Drag and Drop, не обращаясь к консоли NSX.
Блупринты (описания) сервисов как код - теперь их можно импортировать и экспортировать, а также создавать шаблоны описаний для тестовых и производственных сред. Также обновился Management Pack for vRealize Automation.
Улучшенная расширяемость - теперь новый Event Broker позволяет просто подключать сторонние облачные сервисы, например, AWS. vRealize Automation теперь имеет улучшенный API, к которому могут обращаться другие решения.
vRealize Business for Cloud 7.0.1
Теперь этот продукт называется именно так (ранее был просто vRealize Business). Более подробно о его новых возможностях вы можете почитать вот тут, а мы лишь приведем основные нововведения:
Поддержка гибридной модели при учете затрат (Hybrid Cloud Costing).
Более плотная интеграция с vRealize Automation 7.0.
vRealize Operations 6.2
Тут были улучшены следующие вещи (подробнее - тут):
Intelligent Workload Placement - умное размещение рабочих нагрузок по хост-серверам/кластерам в зависимости от нагрузки на них (интеграция с DRS).
Optimal Resource Utilization - средства равномерной загрузки вычислительных ресурсов и хранилищ (появилась возможность сделать Rebalance по нагрузке в рамках кластера).
Proactive Visibility - возможность проактивного мониторинга ресурсов на главном дэшборде.
vRealize Log Insight 3.3
Здесь появилось не так много нового, но об этом можно почитать тут, а пока новые возможности вкратце:
Упрощенная система интеграции со сторонними приложениями и сервисами.
Автоматическое обновление агентов, инициируемое со стороны сервера.
Новое издание vRealize Log Insight for vCenter Standard.
О доступности пакетов VMware vCloud Suite 7 и VMware vRealize Suite 7 будет объявлено дополнительно.
1. Снятие с производства издания vSphere Enterprise.
Да, теперь останутся только 2 издания продукта - vSphere Standard и vSphere Enterprise Plus. Позиционируется это как упрощение лицензирования. В общем-то издание Enterprise всегда было каким-то непонятным (его можно было даже назвать "Enteprise Minus", так как там просто недоставало всего пары вещей, которые были в Plus-издании). Так что этот шаг со стороны VMware хотя и запоздалый, но вполне логичный.
Помимо этого, лицензии VMware vSphere with Operations Management будут доступны только для Enterprise Plus издания. Таким образом, остаются только 3 парт-номера (SKU):
VMware vSphere Standard
VMware vSphere Enterprise Plus
VMware vSphere with Operations Management Enterprise Plus
То есть, сравнительная таблица изданий VMware vSphere теперь выглядит так:
2. Бесплатные лицензии на 25 экземпляров ОС Log Insight.
Все пользователи VMware vCenter Server Standard (как существующие, так и новые) бесплатно получат лицензии на продукт vRealize Log Insight for vCenter Server на 25 экземпляров операционных систем (Operating System Instances, OSI). При этом мониторинг логов будет ограничен продуктами VMware vCenter Server, VMware vSphere и VMware vRealize Log Insight content packs.
3. Изменения цен.
Теперь VMware vSphere with Operations Management Enterprise Plus в американских цена будет стоить $4 395 за процессор хост-сервера (CPU). Ну а VMware vCenter Server Standard будет стоить $5 995 за экземпляр. В России, конечно же, все это будет стоить дороже (да-да, в долларах).
Более подробно об изменениях цен можно прочитать в следующей документе:
В этот раз мы рассмотрим сразу две функции Enable-VMHostSSH/Disable-VMHostSSH моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1. Очень часто администраторам виртуальной инфраструктуры требуется временно включить SSH на хосте/хостах ESXi, например, для запуска esxtop или для выяснения причин PSOD или для решения проблем с СХД...
Мы часто пишем о веб-консоли для управления отдельными хост-серверами VMware ESXi Embedded Host Client, которая для многих администраторов уже стала инструментом, используемым каждый день. На днях компания VMware выпустила обновленную версию ESXi Embedded Host Client v5, которая доступна для загрузки на сайте проекта VMware Labs.
На самом деле, нового в VMware ESXi Embedded Host Client 5 не так много, но говорят, что было исправлено очень много багов:
Хост-серверы
Улучшения в разделе мониторинга производительности (ресайз и поведение тултипов).
Виртуальные машины
Возможность простого экспорта виртуальной машины (базовые функции).
Поддержка клавиатур IT/ES в браузерной консоли.
Исправлены серьезные ошибки при операциях с дисковым контроллером (добавление/удаление, назначение дисков и т.п.).
Хранилища
Исправлена сортировка в datastore browser.
Общие улучшения
Улучшенное поведение таблиц (включая возможности выбора объектов, колонок и фильтрации).
Очередная функция Compare-VMHostSoftwareVibмоего PowerCLI-модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам сравнить установленные VIB-пакеты (vSphere Installation Bundle) между двумя и более хостами ESXi. Функция позволяет сравнивать как два отдельно взятых хоста, так и группу хостов, например, сравнить целый HA/DRS Cluster с эталонным хостом.
Компания VMware выпустила очень интересный документ "VMware vSphere 6
Fault Tolerance
Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.
Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.
1. Процедура компиляции ядра в гостевой ОС.
Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:
2. Сетевая активность.
Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:
Кстати, очевидно, что сетевой трафик именно самой сети FT максимальный, когда машина принимает много данных (их нужно синхронизировать на второй узел), когда же данные передаются там трафик намного меньше (машина их просто отдает, а синхронизировать нужно только сам процесс передачи и параметры канала).
Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:
Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:
3. Тестирование подсистемы ввода-вывода.
Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:
4. Тест Swingbench для Oracle 11g.
Для теста была взята OLTP-нагрузка на базу данных. По числу транзакций в секунду потери небольшие, но задержка по времени ответа возникает значительная:
5. Тест DVD Store на Microsoft SQL Server 2012.
Здесь была запущена симуляция 64 пользовательских сессий. По-сути, этот тест очень похож на методику для Oracle, ну и результаты здесь также соответствующие (но по времени отклика как-то все очень печально):
6. Бенчмарк на базе TPC-E.
Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:
7. Операции VMware vCenter Server.
Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:
vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:
Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.
Всем интересующимся технологиями виртуализации интересно, что же нового готовит компания VMware в своей продуктовой линейке в 2016 году. Специально для вас компания VMware проводит серию онлайн-мероприятий под названием "Enabling the Digital Enterprise", где будут озвучены основные технологические направления виртуализационного гиганта.
Программа мероприятия разбита на треки, посвященные основным направлениям деятельности компании:
Track 1 – Deliver and Secure Your Digital Workspace
Здесь, очевидно, речь пойдет о доставке пользовательских окружений и защите решений в сфере виртуализации приложений и настольных ПК. Попросту говоря, будет рассказано о том, что нового появится в линейке VMware Horizon. Мероприятие пройдет по регионам:
Americas Tuesday, February 9 at 9:30 AM PST
EMEA Wednesday, February 10 at 9:30 AM GMT
Asia Pacific Tuesday, February 16 at 9:00 AM (GMT +11)
Track 2 – Build and Manage Your Hybrid Cloud
Тут уже речь пойдет о построении гибридного облака с помощью решений VMware. То есть, с одной стороны, будут рассказывать о развитии онпремизной серверной линейки продуктов, построенных на платформе VMware vSphere, а с другой стороны, речь пойдет об использовании облачных решений на базе публичного облака VMware vCloud Air.
В рамках трека вам нужно будет выбрать направление cloud management platform (CMP) или hyper-converged infrastructure (HCI), хотя они не являются взаимоисключающими.
Анонс также будет разнесен по времени для различных регионов:
Americas Wednesday, February 10 at 8:30 AM PST
EMEA Thursday, February 11 at 9:30 AM GMT
Asia Pacific Tuesday, February 16 at 9:00 AM (GMT +11)
Больше подробностей о мероприятии можно узнать по этой ссылке, там же можете и зарегистрироваться.
Интересная статья от Дункана Эппинга была опубликована в его блоге пару недель назад. Если вы хотите использовать виртуальные тома VVols, которые обладают некоторыми преимуществами по сравнению с традиционной файловой системой VMware VMFS, то для некоторых систем, поддерживающих механизм VASA (vSphere API for Storage Awareness), потребуется использовать внешний виртуальный модуль VASA Vendor Provider (VP). То есть, некоторые аппаратные хранилища уже содержат в себе готовые модули и прошитые в них модули VP, а вот для некоторых нужно запускать и поддерживать специальную виртуальную машину, выполняющую сервисные функции при работе виртуальных машин с хранилищами VVols.
Прежде всего VP используется для выполнения операции Bind (привязка машины к VVol), которая инициируется при запуске виртуальной машины. В этом случае VP создает точку доступа ввода-вывода (IO access point) для виртуального тома VVol на выбранном Protocol Endpoint (PE). Без этой операции машина не запустится, из чего следует, что критически важно поддерживать виртуальную машину с VP непрерывно доступной. У разных вендоров используются разные уровни доступности:
Кто-то выпускает модуль с возможностью active/standby или active/active-конфигурации виртуальных машин на разных хостах.
Ну а кто-то надеется на встроенные механизмы обеспечения отказоустойчивости VMware HA и VMware Fault Tolerance (FT).
Очевидно, что если вы выбираете хранилище с внешним VP, то очень желательно, чтобы там был реализован первый вариант обеспечения доступности. Ну и нельзя помещать виртуальную машину с VASA VP на том VVol, чтобы не оказаться в ловушке невозможности запуска этой виртуальной машины.
Со временем VMware планирует включить операции bind/unbind в стандарт T10 SCSI, и сервисная виртуальная машина будет не нужна, но эти вещи, как вы понимаете, делаются не быстро, поэтому пока обеспечивайте отказоустойчивость виртуальных модулей VP, по крайней мере, с помощью технологий VMware HA и VMware Fault Tolerance.
И да, в комментарии пишут, что у одного админа получилось так, что машина с VP просто перестала выполнять команды, хотя сама ВМ работала. В результате продуктивные ВМ было не запустить. Поэтому имеет смысл задуматься и об обеспечении отказоустойчивости на уровне компонентов VP (может, как-нибудь проверять скриптами его работоспособность?).
Таги: VMware, VVOls, HA, FT, Storage, vSphere, Hardware
Когда вы ставите один сервер VMware ESXi, то проще всего сделать это, смонтировав ISO-образ через iLO или подобную консоль, либо воткнув загрузочную флешку непосредственно в сервер. Но если у вас несколько хост-серверов ESXi, то делать так уже несолидно для опытного администратора. В целях ускорения процесса он использует процедуру загрузки установщика хоста по сети через механизм PXE, а самые крутые администраторы уже используют средство Auto Deploy, у которого сравнительно недавно появился GUI.
На эту тему компания VMware выпустила очень полезный документ "Installing ESXi Using PXE", в котором эта процедура расписывается по шагам (как для BIOS, так и для UEFI-хостов):
Интересна диаграмма зрелости процесса установки VMware ESXi в организации. Новички прожигают исошку на диск, а крутые перцы - используют Auto Deploy для stateless-хостов:
А вот, например, основная диаграмма последовательности процессов при установке ESXi через PXE:
По шагам процедура выглядит так:
1. Администратор загружает целевой хост ESXi.
2. Этот хост делает DHCP-запрос.
3. DHCP-сервер отвечает с IP-параметрами и расположением TFTP-сервера, который содержит загрузчик.
4. ESXi обращается к серверу TFTP и запрашивает файл загрузчика, который указал DHCP-сервер.
5. TFTP-сервер посылает загрузчик хосту ESXi, который исполняет его. Начальный загрузчик догружает дополнительные компоненты с TFTP-сервера.
6. Загрузчик ищет конфигурационный файл на TFTP-сервере, скачивает ядро и другие компоненты ESXi с HTTP-сервера, который размещен на TFTP-сервере, и запускает ядро на хосте ESXi.
7. Установщик ESXi запускается в интерактивном режиме, либо используя kickstart-скрипт, который указан в конфигурационном файле.
Для автоматизации задач по подготовке ISO-образа ESXi к загрузке через PXE вы можете использовать вот этот полезный скрипт.
Таги: VMware, ESXi, PXE, Boot, Auto Deploy, Whitepaper, vSphere
Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.
Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:
Интересную новость мы обнаружили вот тут. Оказывается утилита esxtop может работать в режиме повтора для визуализации данных о производительности, собранных в определенный период времени (многие администраторы знают это, но далеко не все). Это позволит вам собрать данные о производительности хоста, например, ночью, а в течение рабочего дня проанализировать аномальное поведение виртуальной инфраструктуры VMware vSphere. Называется этот режим replay mode.
Для начала запустите следующую команду для сбора данных на хосте VMware ESXi:
Мы часто пишем о том, что снапшоты в VMware vSphere - это плохо (за исключением случаев, когда они используются для горячего резервного копирования виртуальных машин и временного сохранения конфигурации ВМ перед обновлением).
Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.
Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):
О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.
Сначала посмотрим, какие факторы влияют на время процесса консолидации снапшотов виртуальной машины:
Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
Тип данных в файлах снапшотов (нули или случайные данные).
Нагрузка на хост-сервер ESXi при снятии снапшота.
Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.
Тут надо отметить, что процесс консолидации - это очень требовательный к подсистеме ввода-вывода процесс, поэтому не рекомендуется делать это в рабочие часы, когда производственные виртуальные машины нагружены.
Итак, как можно оценивать производительность процесса консолидации снапшотов:
Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.
Для реализации этого способа нужно, чтобы на хранилище осталась только одна тестовая виртуальная машина со снапшотами. С помощью vMotion/Storage vMotion остальные машины можно с него временно убрать.
1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:
ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"
2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).
3. Запускаем команду мониторинга производительности:
# esxtop
4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.
5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).
Таким образом, зная ваши параметры производительности чтения/записи, а также размер снапшотов и время консолидации тестового примера - вы сможете оценить время консолидации снапшотов для других виртуальных машин (правда, только примерно того же профиля нагрузки на дисковую подсистему).
Смотрим на производительность конкретного процесса консолидации снапшотов.
Это более тонкий процесс, который можно использовать для оценки времени снапшота путем мониторинга самого процесса vmx, реализующего операции со снапшотом в памяти сервера.
1. Запускаем команду мониторинга производительности:
# esxtop
2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.
3. Находим ВМ, на которой идет консолидация.
4. Нажимаем клавишу <e> для раскрытия списка.
5. Вводим Group World ID (это значение в колонке GID).
6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).
7. Нажимаем <u> для отображения статистики дискового устройства.
8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.
9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).
10. Отслеживаем среднее значение в колонке MBWRTN/s.
Это более точный метод оценки и его можно использовать даже при незначительной нагрузке на хранилище от других виртуальных машин.
Не так давно на сайте VMwareArena появилось очередное сравнение VMware vSphere (в издании Enterprise Plus) и Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition, которое включает в себя самую актуальную информацию о возможностях обеих платформ.
Мы адаптировали это сравнение в виде таблицы и представляем вашему вниманию ниже:
Группа возможностей
Возможность
VMware vSphere 6
Enterprise Plus
Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition
Возможности гипервизора
Версия гипервизора
VMware ESXi 6.0
Hyper-V 2012 R2
Максимальное число запущенных виртуальных машин
1024
1024
Максимальное число процессоров (CPU) на хост-сервер
480
320
Число ядер на процессор хоста
Не ограничено
Не ограничено
Максимальное число виртуальных процессоров (vCPU) на хост-сервер
4096
2048
Максимальный объем памяти (RAM) на хост-сервер
6 ТБ
4 ТБ
Техники Memory overcommitment (динамическое перераспределение памяти между машинами)
Memory ballooning
Dynamic Memory
Техники дедупликации страниц памяти
Transparent page sharing
Нет
Поддержка больших страниц памяти (Large Memory Pages)
Да
Да
Управление платформой
Централизованное управление
vCenter Server + vSphere Client + vSphere Web Client, а также виртуальный модуль vCenter Server Appliance (vCSA)
System Center Virtual Machine Manager (SC VMM)
Интеграция с Active Directory
Да, как для vCenter, так и для ESXi-хостов через расширенный механизм SSO
Да (через SC VMM)
Поддержка снапшотов (VM Snapshot)
Да, снапшоты могут быть сделаны и удалены для работающих виртуальных машин
Да, технология Checkpoint, включая функции live export
Управление через браузер (тонкий клиент)
Да, полнофункциональный vSphere Web Client
Ограниченное, через Self Service Portal
Обновления хост-серверов / гипервизора
Да, через VMware Update Manager (VUM), Auto Deploy и CLI
Да - Cluster Aware Updates, Fabric Updates, Management Servers
Управление сторонними гипервизорами
Да, бесплатный аддон Multi-Hypervisor Manager
Да, управление VMware vCenter и Citrix XenCenter поддерживается в SC VMM
Обновление (патчинг) виртуальных машин
Да, через VMware Update Manager (VUM) и vCenter Configuration Manager (vCM)
Да (WSUS, SCCM, VMST)
Режим обслуживания (Maintenance Mode)
Да, горячая миграция ВМ в кластере DRS на другие хосты
Да
Динамическое управление питанием
Да, функции Distributed Power Management в составе DRS
Да, функции Power Optimization в составе Dynamic Optimization
API для решений резервного копирования
Да, vStorage API for Data Protection
Да, VSS API
Шаблоны виртуальных машин (VM Templates)
Да + Multi-site content library
Да, включая шаблоны Gen2
Профили настройки хостов (Host Profiles)
Да, расширенные функции host profiles и интеграция с Auto Deploy
Да, функции Physical Computer Profiles
Решение по миграции физических серверов в виртуальные машины
Да, VMware vCenter Converter
Нет, больше не поддерживается
Горячая миграция виртуальных машин
Да, vMotion между хостами, между датацентрами с разными vCenter, Long Distance vMotion (100 ms RTT), возможна без общего хранилища
Да, возможна без общего хранилища (Shared Nothing), поддержка компрессии и SMB3, неограниченное число одновременных миграций
Горячая миграция хранилищ ВМ
Да, Storage vMotion, возможность указать размещение отдельных виртуальных дисков машины
Да
Профили хранилищ
Да, Storage policy-based management
Да, Storage Classifications
Кластер непрерывной доступности ВМ
Да, Fault Tolerance с поддержкой до 4 процессоров ВМ, поддержка различных типов дисков, технология vLockstep
Нет
Конфигурации виртуальных машин
Виртуальных процессоров на ВМ
128 vCPU
64 vCPU
Память на одну ВМ
4 ТБ
1 ТБ
Последовательных портов (serial ports)
32
Только присоединение к named pipes
Поддержка USB
До 20 на одну машину (версии 1,2 и 3)
Нет (за исключением Enhanced Session Mode)
Горячее добавление устройств
(CPU/Memory/Disk/NIC/PCIe SSD)
Только диск и память (память только, если настроена функция Dynamic memory)
Диски, растущие по мере наполнения данными (thin provisioning)
Да (thin disk и se sparse)
Да, Dynamic disks
Поддержка Boot from USB
Да
Нет
Хранилища на базе локальных дисков серверов
VMware Virtual SAN 6.0 с поддержкой конфигураций All Flash
Storage Spaces, Tiered Storage
Уровни обслуживания для подсистемы ввода-вывода
Да, Storage IO Control (работает и для NFS)
Да, Storage QoS
Поддержка NPIV
Да (для RDM-устройств)
Да (Virtual Fibre Channel)
Поддержка доступа по нескольким путям (multipathing)
Да, включая расширенную поддержку статусов APD и PDL
Да (DSM и SMB Multichannel)
Техники кэширования
Да, vSphere Flash Read Cache
Да, CSV Cache
API для интеграции с хранилищами
Да, широкий спектр VASA+VAAI+VAMP
Да, SMI-S / SMP, ODX, Trim
Поддержка NIC Teaming
Да, до 32 адаптеров
Да
Поддержка Private VLAN
Да
Да
Поддержка Jumbo Frames
Да
Да
Поддержка Network QoS
Да, NetIOC (Network IO Control), DSCP
Да
Поддержка IPv6
Да
Да
Мониторинг трафика
Да, Port mirroring
Да, Port mirroring
Подводя итог, скажем, что нужно смотреть не только на состав функций той или иной платформы виртуализации, но и необходимо изучить, как именно эти функции реализованы, так как не всегда реализация какой-то возможности позволит вам использовать ее в производственной среде ввиду различных ограничений. Кроме того, обязательно нужно смотреть, какие функции предоставляются другими продуктами от данного вендора, и способны ли они дополнить отсутствующие возможности (а также сколько это стоит). В общем, как всегда - дьявол в деталях.
Таги: VMware, vSphere, Hyper-V, Microsoft, Сравнение, ESXi, Windows, Server
Компания VMware выпустила первое после нового года обновление своей серверной платформы виртуализации - VMware vSphere 6.0 Update 1b, включая обновления vCenter и ESXi.
Новых возможностей, конечно же, немного, но все же компоненты vSphere рекомендуется обновить ввиду наличия критичных обновлений подсистемы безопасности.
Что нового в VMware vCenter Server 6.0 Update 1b:
Поддержка метода обновления URL-based patching с использованием zip-пакета. Подробнее в KB 2142009.
Пользовательские настройки для Client Integration Plugin или диалогового окна VMware-csd guard в vSphere Web Client могут быть переопределены. Подробнее в KB 2142218.
vSphere 6.0 Update 1b включает поддержку TLS версий 1.1 и 1.2 для большинства компонентов vSphere без нарушения совместимости с предыдущими версиями. Компоненты которые по-прежнему поддерживают только TLS версии 1.0:
vSphere Client
Virtual SAN Observer на сервере vCenter Server Appliance (vCSA)
Syslog на сервере vCSA
Auto Deploy на vCSA
Auto Deploy на iPXE
О поддержке TLS-протоколов можно почитать подробнее в KB 2136185 .
Утилита certificate manager теперь автоматически вызывает скрипт updateExtensionCertInVC.py для обновления хранилищ сертификатов, которые построены не на базе VMware Endpoint Certificate Store (VECS).
Множество исправлений ошибок.
Что нового в VMware ESXi 6.0 Update 1b:
Поддержка TLS версий 1.1 и 1.2 для большинства компонентов без нарушения совместимости с предыдущими версиями.
Поддержка Advanced Encryption Standard (AES) с длиной ключа 128/256 бит для аутентификации через NFS 4.1 Client.
Исправления ошибок.
Скачать VMware vCenter Server 6.0 Update 1b и VMware ESXi 6.0 Update 1b можно по этой ссылке.
Иногда системному администратору VMware vSphere требуется узнать, сколько тот или иной хост ESXi работает с момента последней загрузки (например, требуется проверить, не было ли внеплановых ребутов).
Есть аж целых 5 способов сделать это, каждый из них можно применять в зависимости от ситуации.
1. Самый простой - команда uptime.
Просто заходим на хост ESXi из консоли или по SSH и выполняем команду uptime:
login as: root
Using keyboard-interactive authentication.
Password: XXXXXX
The time and date of this login have been sent to the system logs.
VMware offers supported, powerful system administration tools. Please
see www.vmware.com/go/sysadmintools for details.
The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # uptime
04:26:24 up 00:20:42, load average: 0.01, 0.01, 0.01
2. С помощью команды esxtop.
С помощью утилиты esxtop можно не только отслеживать производительность хоста в различных аспектах, но и узнать его аптайм. Обратите внимание на самую первую строчку вывода:
# esxtop
4. Время запуска хоста из лога vmksummary.log.
Вы можете посмотреть не только время текущего аптайма хоста ESXi, но времена его прошлых запусков в логе vmksummary.log. Для этого выполните следующую команду:
cat /var/log/vmksummary.log |grep booted
2015-06-26T06:25:27Z bootstop: Host has booted
2015-06-26T06:47:23Z bootstop: Host has booted
2015-06-26T06:58:19Z bootstop: Host has booted
2015-06-26T07:05:26Z bootstop: Host has booted
2015-06-26T07:09:50Z bootstop: Host has booted
2015-07-08T05:32:17Z bootstop: Host has booted
4. Аптайм в vSphere Client и Web Client.
Если вы хотите вывести аптайм сразу всех виртуальных машин на хосте в VMware vSphere Client, для этого есть специальная колонка в представлении Hosts:
5. Аптайм хостов через PowerCLI.
Конечно же, время работы хоста ESXi можно посмотреть и через интерфейс PowerCLI. Для этого нужно воспользоваться командлетом Get-VMHost:
Какое-то время назад мы писали о технологии доставки приложений пользователям инфраструктуры настольных ПК предприятия - VMware App Volumes (ранее это называлось Cloud Volumes). Суть ее заключается в том, что виртуализованные и готовые к использованию приложения VMware ThinApp доставляются пользователям в виде подключаемых виртуальных дисков к машинам.
Недавно компания VMware выпустила документ "VMware App Volumes Reference Architecture", в котором объясняется работа технологии App Volumes, рассматривается референсная архитектура этого решения, а также проводится тестирование производительности доставляемых таким образом приложений по сравнению с их нативной установкой внутри виртуальных ПК:
Собственно, типовая архитектура решения App Volumes выглядит следующим образом:
Здесь показаны основные компоненты такой инфраструктуры:
AppStacks - это тома, которые содержат сами установленные приложения и работают в режиме Read Only. Их можно назначить пользователям Active Directory, группам или OU. Один такой диск может быть назначен сразу нескольким виртуальным ПК (по умолчанию доступен всем машинам датацентра).
Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами.
App Volumes Manager Server - это Windows-сервер, содержащий административную консоль для настройки продукта и управления им.
В качестве референсной архитектуры используется инфраструктура из 2000 виртуальных ПК, запущенных на 18 хостах ESXi инфраструктуры VMware Horizon View:
Для генерации нагрузки использовались различные сценарии пользовательского поведения, создаваемые с помощью средства Login VSI, ставшего уже стандартом де-факто для тестирования VDI-инфраструктур, развернутого на трех хост-серверах.
Здесь описаны 3 варианта тестирования:
Приложения, нативно установленные в виртуальных ПК.
Приложения App Volumes, использующие один AppStack, содержащий основные приложения пользователей.
Приложения App Volumes, распределенные по трем различным AppStack.
Для обоих случаев тестирования App Volumes использовался один Writable Volume. Тут были получены следующие результаты (больше очков - это лучше).
Посмотрим на время логина пользователей при увеличении числа одновременных сессий в референсной архитектуре:
Взглянем на время отклика приложений:
Оценим время запуска приложений:
В целом-то, нельзя сказать, что потери производительности незначительные - они, безусловно, чувствуются. Но радует, что они фиксированы и хорошо масштабируются при увеличении числа одновременных сессий в VDI-инфраструктуре.
Документ очень полезен для оценки потерь производительности с точки зрения User Experience при использовании App Volumes по сравнению с традиционной доставкой приложений. Скачать 50-страничный документ можно скачать по этой ссылке - почитайте, там действительно интересно все изложено.
Имя компьютера/сервера не всегда является достаточно информативным, например, имя «DC01» скажет вам намного меньше, чем «DC: Сайт Москва - GC, FSMO: Schema, RID, PDC». Поскольку имя компьютера NetBIOS/Hostname имеет ограничения как по длине, так и по набору символов, то для хранения этой дополнительной информации и предназначено поле «Description». Оно существует как для компьютера, т.е. внутри ОС (System Properties)...
Пару месяцев назад мы писали о том, что вышло обновление VMware vSphere 5.5 Update 3, которое полезно для пользователей, еще не перешедших на обновленную версию платформы виртуализации vSphere 6.
Новых возможностей там было немного, поэтому многие проигнорировали этот апдейт - а зря. Там появилось множество улучшений производительности операций в Web Client, о чем у VMware есть отдельная статья. Приведем основную выжимку здесь.
Как вы знаете, в vSphere Web Client 6.0 был сделан шаг вперед в плане улучшения производительности, а сейчас инженеры VMware портировали эти изменения уже на младшую версию vSphere 5.5 U3. При этом, по оценке самой VMware, теперь производительность тонкого клиента в этой версии в некоторых аспектах аналогична оной в vSphere 6.0 Update 1.
Улучшения были сделаны в следующих областях:
Меню действий и меню по правому клику мыши
Страницы Related Objects, Summary и Settings
Мастера выполнения операций (миграция, создание шаблона и т.п.)
Процесс логина в консоль
Графики отображения производительности
Для тестирования сделанных улучшений (VMware уверяет, что их было сделано очень много) использовались 2 типа окружения:
Большое – vCenter Server (32 vCPU / 64 GB RAM), 1000 хостов, 15000 ВМ
Посмотрим на время логина в Web Client:
Уменьшилось ровно в 2 раза. Теперь посмотрим на отклик меню действий (оно же вызывается по правой кнопке мыши):
Здесь кое-где и в 3 раза улучшилась ситуация. Для меню виртуальных машин ситуация не сильно улучшилась, так как в этом меню большое количество контекстно-зависимых действий.
Генерация графиков производительности (выбор объектов, ресайз графиков, обновление, выбор элементов для отображения). Здесь очень существенные улучшения, более чем в 2 раза:
Отображение связанных объектов, например, вы выбираете кластер и отображения списка виртуальных машин в нем происходит намного быстрее:
В общем, если вы еще не обновились - причина поставить новую версию Web Client есть.
Таги: VMware, Web Client, Performance, Update, vSphere
Как вы знаете, некоторое время назад вышло обновление платформы виртуализации VMware vSphere 6 Update 1, в котором были, в основном, только минорные обновления. Но было и важное - теперь виртуальный модуль VMware vCenter Server Appliance (vCSA) стало возможно обновлять путем монтирования к нему ISO-образа с апдейтом.
Давайте покажем упрощенный процесс обновления через смонтированный образ. Итак, соединимся с хостом vCSA по SSH (если у вас есть отдельный сервер Platform Services Controller, то коннектиться нужно к нему):
Далее скачаем обновление vCenter, в котором есть и обновление vCSA версии 6.0.0 (выберите продукт VC и в разделе VC-6.0.0U1-Appliance скачайтеVMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso):
Здесь надо пояснить, что это за обновления:
FP (Full patch) - это обновление всех компонентов vCenter, включая полноценные продукты, vCenter, vCSA, VMware Update Manager, PSC и прочее.
TP (Third party patch) - это обновление только отдельных компонентов vCenter.
Скачиваем патч FP (VMware-vCenter-Server-Appliance-6.0.0.10000-3018521-patch-FP.iso), после чего монтируем этот ISO-образ к виртуальной машине vCSA через vSphere Web Client или Embedded Host Client.
Далее возвращаемся к консоли vCSA:
Смонтировать ISO-образ можно также через PowerCLI с помощью следующих команд:
Далее выполняем следующую команду, если вы хотите накатить патчи прямо сейчас:
software-packages install --iso --acceptEulas
Либо патчи можно отправить на стейджинг отстаиваться (то есть пока обновить компоненты, но не устанавливать). Сначала выполняем команду отсылки на стейджинг:
software-packages install --iso --acceptEulas
Далее просматриваем содержимое пакетов:
software-packages list --staged
И устанавливаем апдейт со стейджинга:
software-packages install --staged
Если во время обновления на стейджинг или установки обновления возникли проблемы, вы можете просмотреть логи, выполнив следующие команды:
shell.set –enabled True shell cd /var/log/vmware/applmgmt/ tail software-packaged.log –n 25
Далее размонтируйте ISO-образ от виртуальной машины или сделайте это через PowerCLI следующей командой:
shutdown reboot -r "Updated to vCenter Server 6.0 Update 1"
Теперь откройте веб-консоль vCSA по адресу:
https://<FQDN-or-IP>:5480
И перейдите в раздел Update, где вы можете увидеть актуальную версию продукта:
Кстати, обратите внимание, что возможность проверки обновления в репозитории (Check URL) вернулась, и обновлять vCSA можно прямо отсюда по кнопке "Check Updates".
Мы уже писали о том, что последней версии решения для виртуализации настольных ПК VMware Horizon View 6.2 есть поддержка режима vGPU. Напомним, что это самая прогрессивная технология NVIDIA для поддержки требовательных к производительности графической подсистемы виртуальных десктопов.
Ранее мы уже писали про режимы Soft 3D, vSGA и vDGA, которые можно применять для виртуальных машин, использующих ресурсы графического адаптера на стороне сервера.
Напомним их:
Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
vDGA - выделение отдельного графического адаптера (GPU) одной виртуальной машине.
vSGA - использование общего графического адаптера несколькими виртуальными машинами.
Режим vSGA выглядит вот так:
Здесь графическая карта представляется виртуальной машине как программный видеодрайвер, а графический ввод-вывод обрабатывается через специальный драйвер в гипервизоре - ESXi driver (VIB-пакет). Команды обрабатываются по принципу "first come - first serve".
Режим vDGA выглядит вот так:
Здесь уже физический GPU назначается виртуальной машине через механизм проброса устройств DirectPath I/O. То есть целый графический адаптер потребляется виртуальной машиной, что совсем неэкономно, но очень производительно.
В этом случае специальный драйвер NVIDIA GPU Driver Package устанавливается внутри виртуальной машины, а сам режим полностью поддерживается в релизах Horizon View 5.3.х и 6.х (то есть это давно уже не превью и не экспериментальная технология). Этот режим работает в графических картах K1 и K2, а также и более свежих адаптерах, о которых речь пойдет ниже.
Режим vGPU выглядит вот так:
То есть встроенный в гипервизор NVIDIA vGPU Manager (это тоже драйвер в виде пакета ESXi VIB) осуществляет управление виртуальными графическими адаптерами vGPU, которые прикрепляются к виртуальным машинам в режиме 1:1. В операционной системе виртуальных ПК также устанавливается GRID Software Driver.
Здесь уже вводится понятие профиля vGPU (Certified NVIDIA vGPU Profiles), который определяет типовую рабочую нагрузку и технические параметры десктопа (максимальное разрешение, объем видеопамяти, число пользователей на физический GPU и т.п.).
vGPU можно применять с первой версией технологии GRID 1.0, которая поддерживается для графических карт K1 и K2:
Но если мы говорим о последней версии технологии GRID 2.0, работающей с адаптерами Tesla M60/M6, то там все устроено несколько иначе. Напомним, что адаптеры Tesla M60 предназначены для Rack/Tower серверов с шиной PCIe, а M6 - для блейд-систем различных вендоров.
Технология NVIDIA GRID 2.0 доступна в трех версиях, которые позволяют распределять ресурсы между пользователями:
Характеристики данных лицензируемых для адаптеров Tesla изданий представлены ниже:
Тут мы видим, что дело уже не только в аппаратных свойствах графической карточки, но и в лицензируемых фичах для соответствующего варианта использования рабочей нагрузки.
Каждый "experience" лицензируется на определенное число пользователей (одновременные подключения) для определенного уровня виртуальных профилей. Поэтому в инфраструктуре GRID 2.0 добавляется еще два вспомогательных компонента: Licensing Manager и GPU Mode Change Utility (она нужна, чтобы перевести адаптер Tesla M60/M6 из режима compute mode в режим graphics mode для работы с соответствующим типом лицензии виртуальных профилей).
Обратите внимание, что поддержка гостевых ОС Linux заявлена только в последних двух типах лицензий.
На данный момент сертификацию драйверов GRID прошло следующее программное обеспечение сторонних вендоров (подробнее об этом тут):
Спецификации карточек Tesla выглядят на сегодняшний день вот так:
Поддержка также разделена на 2 уровня (также прикрепляется к лицензии):
Руководство по развертыванию NVIDIA GRID можно скачать по этой ссылке, ну а в целом про технологию написано тут.
Те, из вас, кто пользуется веб-средством vSphere Web Client для управления виртуальной инфраструктурой VMware vSphere, знают, что при логине в окно клиента в самом низу предлагают скачать Client Integration Plugin (CIP):
CIP - это пакет средств от VMware, представляющий собой набор полезных утилит для некоторых административных операций в виртуальной инфраструктуре. Утилиты доступны как для Microsoft Windows, так и для Apple Mac OS X (а скоро будет и поддержка Linux).
Посмотрим на состав этого набора:
ovftool - это отдельная утилита CLI, которую можно использовать для импорта и экспорта виртуальных модулей (Virtual Appliances) в форматах OVF и OVA.
Windows Authentication - позволяет использовать аутентификацию SSPI Windows при логине через vSphere Web Client.
Remote Devices - возможность подключить клиентские устройства (CD-ROM, Floppy, USB и прочие) к виртуальной машине.
File Upload/Download - это вынесенный в отдельную утилиту Datastore browser для загрузки файлов на виртуальные хранилища.
Content Library - операции импорта и экспорта для компонента Content Library.
Client Side Logging/Config - позволяет записывать логи на стороне клиента, а также реализует настройки логирования vSphere Web Client.
Процедура развертывания vSphere Client Integration Plugin выглядит примерно так (видео от версии vSphere 5.5):
Ранее CIP как браузерный плагин использовал модель Netscape Plugin Application Programming Interface (NPAPI), но поскольку в Google Chrome последних версий и прочих браузерах поддержка этой устаревшей модели была окончена, то теперь используется обновленная модель отображения, которая реализована, начиная с Sphere 5.5 Update 3a и vSphere 6.0 Update 1 (поэтому лучше CIP использовать с платформами этих версий или выше).
Более подробно об утилитах CIP рассказано вот тут.
Для тех из вас, кто еще не обновил свою инфраструктуру на последнюю версию VMware vSphere 6, компания VMware приготовила очередной пакет исправлений VMware vSphere 5.5 Update 3b. На самом деле, это просто патч VMware ESXi 5.5 patch ESXi550-201512001, в котором произошли некоторые изменения в плане безопасности, а также исправлены ошибки.
Среди заявленных фич, касающихся security, основная - это отключенный по умолчанию SSL третьей версии (SSLv3). Отключили его (как в клиенте, так и в сервере) потому, что он считается устаревшим, и его поддержка уже не предоставляется в большинстве Enterprise-продуктов (об этом можно почитать в RFC 7568).
Внимание! Обязательно следуйте рекомендованной последовательности обновления продуктов VMware, то есть сначала обновите vCenter до версии 5.5 Update 3b и только потом ESXi 5.5 до версии Update 3b, чтобы избежать проблем с отключением хостов от сервера управления vCenter.
Также помните, что VMware View Composer версии ниже 6.2 не будет работать с хостами ESXi 5.5 Update 3b.
На блогах VMware появился интересный пост про производительность виртуальных машин, которые "растянуты" по ресурсам на весь физический сервер, на котором они запущены. В частности, в посте речь идет о сервере баз данных, от которого требуется максимальная производительность в числе транзакций в секунду (см. наш похожий пост о производительности облачного MS SQL здесь).
В данном случае речь идет о виртуализации БД с типом нагрузки OLTP, то есть обработка небольших транзакций в реальном времени. Для тестирования использовался профиль Order-Entry, который основан на базе бенчмарка TPC-C. Результаты подробно описаны в открытом документе "Virtualizing Performance Critical Database Applications in VMware vSphere 6.0", а здесь мы приведем основные выдержки.
Сводная таблица потерь на виртуализацию:
Метрика
Нативное исполнение нагрузки
Виртуальная машина
Пропускная способность транзакций в секунду
66.5K
59.5K
Средняя загрузка логических процессоров (72 штуки)
84.7%
85.1%
Число операций ввода-вывода (Disk IOPS)
173K
155K
Пропускная способность ввода-вывода дисковой подсистемы (Disk Megabytes/second)
929MB/s
831MB/s
Передача пакетов по сети в секунду
71K/s receive
71K/s send
63K/s receive
64K/s send
Пропускная способность сети в секунду
15MB/s receive
36MB/s send
13MB/s receive
32MB/s send
А вот так выглядит график итогового тестирования (кликабельно):
Для платформы VMware ESXi 5.1 сравнивалась производительность на процессоре микроархитектуры Westmere, а для ESXi 6.0 - на процессорах Haswell.
Результаты, выраженные в числе транзакций в секунду, вы видите на картинке. Интересно заметить, что ESXi версии 6.0 всерьез прибавил по сравнению с прошлой версией в плане уменьшения потерь на накладные расходы на виртуализацию.
А вот так выглядят усредненные значения для версий ESXi в сравнении друг с другом по отношению к запуску нагрузки на нативной платформе:
Ну и несложно догадаться, что исследуемая база данных - это Oracle. Остальное читайте в интереснейшем документе.
VMware PowerCLI – это весьма мощный инструмент управления, а всё, что нужно сделать для начала работы с ним - это подключиться к серверу или серверам виртуальной инфраструктуры, которыми могут являться сервер управления vCenter Server, Linux vCenter Server Appliance (vCSA) или ESXi-хост.
Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.
Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.
И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.
Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:
ESXi600-201511401-BG
Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:
Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:
Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).
SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.
SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:
То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.
Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.
Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.
Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.
Итак, как именно работает кэширование на SSD в VMware Virtual SAN:
1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.
2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).
3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.
4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.
5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.
6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.
В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!
Компания VMware на днях представила проект VMware Sample Exchange, представляющий собой портал, где разработчики выкладывают для загрузки различные шаблоны сценариев, помогающие в решении повседневных задач по администрированию виртуальной инфраструктуры VMware vSphere.
На этом сайте можно найти не только сценарии сотрудников VMware на языках/оболочках PowerShell/PowerCLI, Python, Ruby, Java и других, но и предложить свой вариант решения задачи или запросить его у сообщества профессионалов, которые будут там тусоваться (потому и называется Exchange). На данный момент на портале есть контент от таких известных многим людей, как Alan Renouf и William Lam.
Сейчас загружать свой контент и сценарии могут только носители звания VMware vExpert и авторизованные со стороны VMware люди, но в релизной версии сервиса это смогут сделать все желающие (на данный момент обсуждения по этим вопросам находятся вот тут).
В левой колонке портала находятся фильтры по категориям применения сценариев (платформы, решения VMware и бизнес-задачи):
А также по языку программирования/интерфейсу:
Пока в библиотеке всего 260 сэмплов (нераспиханных по категориям и интерфейсам), но будем надеяться, что скоро коллекция существенно расширится и там наведут порядок.
Недавно мы писали о серьезном баге в механизме Changed Block Tracking (CBT) платформы VMware vSphere 6, который приводит к тому, что инкрементальные резервные копии виртуальных машин оказываются невосстановимыми.
Это, конечно, очень неприятное известие, но не для пользователей решения Veeam Backup and Replication, так как там есть возможность отключить поддержку глючной технологии CBT. Для этого идем в свойства задачи резервного копирования (Edit Backup Job) и выбираем там пункт "Advanced":
И на вкладке vSphere расширенных настроек убираем галку "Use changed block tracking data (recommended)":
Это приведет к тому, что при создании инкрементальных резервных копий Veeam B&R при следующем запуске задачи не будет использовать технологию CBT для отслеживания изменившихся блоков, а значит при создании инкремента бэкапа будут сравниваться все блоки диска ВМ на отличия от бэкапа. Это займет большее время, но ваша резервная копия гарантированно окажется восстановимой.
Такое вот приятное отличие Veeam Backup and Replication от других продуктов для резервного копирования позволит вам продолжать использовать технологии резервного копирования в производственной среде в то время как все остальные пользователи (которые без B&R) страдают и воют от безысходности.
На сайте проекта VMware Labs, где сотрудники VMware частенько публикуют различного рода утилиты для инфраструктуры VMware vSphere, появилось обновление очень полезной штуки, которое все очень давно ждали - VMware Auto Deploy GUI. Напомним, что о прошлой верcии этого средства мы писали вот тут.
Теперь вы можете проводить преднастройку профилей и развертывание новых хостов VMware ESXi 6 для Stateless-окружения прямо из графического интерфейса VMware vSphere Client:
Auto Deploy GUI - это плагин к vSphere Client, реализующий основные функции VMware vSphere Auto Deploy, такие как:
Создание/редактирование правил соответствия хостов и профилей образов.
Проверка соответствия хостов этим правилам и восстановление этого соответствия.
Новые возможности последней версии Auto Deploy GUI:
Поддержка VMware vSphere 6.0.
В мастере Image Profile Wizard появились новые функции "VIB filter".
Новые средства "PXE Host List and Boot Configuration troubleshooting" для решения проблем с загрузкой хостов.
Надо отметить, что это последняя версия Auto Deploy GUI, которая поддерживает VMware vSphere версии 5.0. Скачать VMware Auto Deploy GUI можно по этой ссылке. Ну и порекомендуем очень полезный документ "VMware Auto Deploy GUI Practical Guide".
RSS
